\subsection{Cache individual vs Cache partilhado}
\label{sec:discachecmp}

Desde o início do trabalho previu-se que a implementação de cache partilhado viria sofrer num contexto com múltiplos threads, pois numa situação em que os threads trabalhem em linhas diferentes o cache estaria continuamente a ser alterado. Este benchmark veio a confirmar esse raciocínio. O $CJDBC_SM$ tem um desempenho inferior ao de $CJDBC_I$. 

Do \emph{fetch size} de 10\% para 20\% nota-se uma perda de desempenho do $CJDBC_S$. Isto acontece porque com um cache maior, a sua actualização torna-se numa operação mais pesada, e o maior número de linhas não chega para compensar a sua actualização. 
Para o fetch size 50\% e 75\% nota-se uma muito ligeira recuperação do $CJDBC_SM$, e para 100\% ambos ($CJDBC_I$ e $CJDBC_SM$) têm desempenhos próximos para quantidades de threads mais baixas. Este dado vem contribuir para a justificação da assunção de que a implementação do cache partilhado deveria guardar todas as linhas no cache.

Existe mais um aspecto importante a referir. Embora para o \emph{fetch size} a 100\% o $CJDBC_SM$ se tenha aproximando do $CJDBC_I$, ainda ficou aquém. Mas pelo que se tinha visto na comparação com o $MSJDBC$, o $CJDBC_S$ tinha melhor desempenho do que o $CJDBC_I$. Isto aconteceu porque teve que ser criada uma nova versão do $CJDBC_S$ que suportasse diferentes tamanhos de \emph{fetch size}. A versão oficial da implementação do cache partilhado está optimizada para tirar partido do facto de o cache conter todas as linhas, e não ser necessário verificar se uma linha requisitada se encontra em cache.
Nos resultados da comparação da comparação entre $CJDBC_I$ e $CJDBC_S$ verifica-se uma grande superioridade do $CJDBC_S$, o que comprova que o cache partilhado deve conter a totalidade das linhas do result set em cache.
